Thank you for the PR!

My comment in #15592 was not particularly referring to #15543, but was rather a general question, since there are already several exported functions (mostly JIT related); or is that because JIT can be built as separate DSO? Ah, looking at Makefile.frag it is likely about the library objects (.lo) which are used on non Windows systems.

This will prevent an ability to change opcache internals in minor releases, that may be required for bug fixes.
Historically opcache was an encapsulated self contained extension that should be completely transparent for the other parts of PHP.

I wouldn't like to export this internals.

My comment in #15592 was not particularly referring to #15543, but was rather a general question, since there are already several exported functions (mostly JIT related); or is that because JIT can be built as separate DSO? Ah, looking at Makefile.frag it is likely about the library objects (.lo) which are used on non Windows systems.

I suppose we don't need ZEND_EXT_API in JIT.
I can't remember why they were added (may be by mistake or may be because of some workaround).
I'll try remove these unintended ZEND_EXT_API usages.

@dstogov, not exporting the headers makes generally sense to me, but if we export smm_shared_globals there should be at least a minimal public header to make that useful (possibly "hiding" members which are not supposed to be accessed by importers); otherwise importers will have to use their own headers (or accessing by offset) which is likely to cause issues for them, when OPcache makes ABI breaking changes.

@dstogov, not exporting the headers makes generally sense to me, but if we export smm_shared_globals there should be at least a minimal public header to make that useful (possibly "hiding" members which are not supposed to be accessed by importers); otherwise importers will have to use their own headers (or accessing by offset) which is likely to cause issues for them, when OPcache makes ABI breaking changes.

Look, observer guys needed some data from opcache, and they made yet another quick hack...
Of course, this might be done through extending opcache_get_status() without any magic, but ... I gave up. :(
I don't like to care about the problems they make for their selves. I only like to minimize the problems introduced for the PHP core and opcache.

I see. Then I suggest to not publish any OPcache headers to reduce maintenance burden of PHP/ZE, and to not pursue #15592 wrt OPcache. Since there is no mention of the newly exported global in UPGRADING.INTERNALS anyway, only those knowing about that may use it, but we should not further advertize it. :)

This will prevent an ability to change opcache internals in minor releases, that may be required for bug fixes. Historically opcache was an encapsulated self contained extension that should be completely transparent for the other parts of PHP.

I can see what you mean and I am totally okay with not exposing the headers, especially as these structures have been pretty stable in the past.